Apple has many enhancements planned for the Macintosh family of computers. To help ensure your software’s compatibility with these enhancements, check each item in this note to be sure that you’re following the recommendations.
If your software is written in a high-level language like Pascal or C and if you adhere to the guidelines listed in Inside Macintosh, many of the questions in this note won’t concern you. If you develop in assembly language, you should read each question carefully. If you answer any question “yes,” your software may encounter difficulty running on future Macintosh computers, and you should take the recommended action to change your software.
Do you depend on 68000 instructions which require that the processor be in supervisor mode?
In general, your software should not include instructions which depend on supervisor mode. These include modifying the contents of the status register. Most programs which modify the status register are only changing the Condition Code Register (CCR) half of the status register, so an instruction which addresses the CCR will work fine. Also, your software should not use the User Stack Pointer (USP) or turn interrupts on and off.
Do you have code which executes in response to an exception and relies on the position of data in the exception’s local stack frame?
Exception stack frames vary on different microprocessors in the 68000 family, some of which may be used in future Macintosh computers. You should avoid using the TRAP instruction. Note: You can determine which microprocessor is installed by examining the low-memory global CPUFlag (a byte at $12F). These are the values:
CPUFlag microprocessor
$00 68000
$01 68010
$02 68020
$03 68030
Do you use low-memory globals not documented in Inside Macintosh?
Other microprocessors in the 68000 family use the exception vectors in locations $0 through $FF in different ways. No undocumented location below the system heap ($100 through $13FF) is guaranteed to be available for use in future systems.
Do you make assumptions about the file system which are not consistent with both the original Macintosh File System and the Hierarchical File System?
Your applications should be compatible with both file systems. The easiest way to do this is to stick to the old files system trap calls (which work with both file systems) and avoid direct manipulation of data structures such as file control blocks and volume control blocks whenever possible.
Do you depend on the system or application heaps starting at a hard-coded address?
The starting addresses and the size of the system and application heaps has already changed (Macintosh vs. Macintosh Plus) and will change again in the future. Use the global ApplZone to find the application heap and SysZone to find the system heap. Also, don’t count on the application heap zone starting at an address less than 65536 (that is, a system heap smaller than 64K).
Do you look through the system’s queues directly?
In general, you should avoid examining queue elements directly. Instead, use the Operating System calls to manipulate queue elements.
Do you directly address memory-mapped hardware such as the VIA, the SCC, or the IWM?
You should avoid accessing this memory directly and use trap calls instead (disk driver, serial driver, etc.). Future machines may include a memory management unit (MMU) which may prevent access to memory-mapped hardware. Also, these memory-mapped devices may not be present on future machines. The addresses of these devices are likely to change, so if you must access the hardware directly, get the base address of the device from the appropriate low-memory global (obtainable from includes and interface files):
device global
VIA $1D4
SCCRd $1D8
SCCWr $1DC
IWM $1E0
Do you assume the location or size of the screen?
The location, size, and bit depth of the screen is different in various machines. You can determine its location and size by examining the QuickDraw global variable screenBits on machines without Color QuickDraw. On machines with Color QuickDraw, the device list, described in the Graphics Devices chapter of Inside Macintosh, tells the location and size and bit depth of each screen, screenBits contains the location and size of the main device, and GrayRgn contains a region describing the shape and size of the desktop.
Does your software fail on some Macintosh models or on A/UX?
If so, you should determine the reason. Failure to run on all versions of the Macintosh may indicate problems which will prevent your software from working on future machines. Failture to run on A/UX, Apple’s Unix for the Macintosh, also may indicate such problems.
Do you change master pointer flags of relocatable blocks directly with BSET or BCLR instructions?
In the future and on A/UX, all 32 bits of a master pointer may be used, with the flags byte moved elsewhere. Use the Memory Manager calls HPurge, HNoPurge, HLock, HUnlock, HSetRBit, HClrRBit, HGetState, and HSetState to manipulate the master pointer flags. (See the Memory Manager chapter of Inside Macintosh Volume IV for information on these calls.)
Do you check for 128K, 512K, and 1M RAM sizes?
You should be flexible enough to allow for non-standard memory sizes. This will allow your software to work in environments like MultiFinder.
Is your software incompatible with a third-party vendor’s hardware?
If so, the incompatibility may prevent your software from working on future machines. You should research the incompatibility and try to determine a solution.
Do you rely on system resources being in RAM?
On most of our systems, some system resources are in ROM. You should not assume, for example, that you can regain RAM space by releasing system resources.
Does your software have timing-sensitive code?
Various Macintoshes run at different clock speeds, so timing loops will be invalid. You can use the trap call Delay for timing, or you can examine the global variable Ticks.
Do you have code which writes to addresses within the code itself?
A memory management unit (MMU) may one day prevent code from writing to addresses within code memory. Also, some microprocessors in the 68000 family cache code as it’s encountered. Your data blocks should be allocated on the stack or in heap blocks separate from the code, and your code should not modify itself.
Do you rely on keyboard key codes rather than ASCII codes?
The various keyboards are slightly different; future keyboards may be different from them. For textual input, you should read ASCII codes rather than key codes.
Do you rely on the format of packed addresses in the trap dispatch table?
The trap dispatch table is different on various Macintoshes. There’s no guarantee of the trap table’s format in the future. You should use the system calls GetTrapAddress and SetTrapAddress to manipulate the trap dispatch table.
Do you use the Resource Manager calls AddReference or RmveReference?
These calls have been removed from the 128K ROM. They are no longer supported.
Do you store information in the application parameters area (the 32 bytes between the application and unit globals and the jump table)?
This space is reserved for use by Apple.
Do you depend on values in registers after a trap call, other than those documented in Inside Macintosh?
These values aren’t guaranteed. The register conventions documented in Inside Macintosh will, of course, be supported. Often, you may not realize that your code is depending on these undocumented values, so check your register usage carefully.
Do you use the IMMED bit in File Manager calls?
This bit, which was documented in early versions of Inside Macintosh as a special form of File Manager call, actually did nothing for File Manager calls, and was used only for Device Manager calls. With the advent of the Hierarchical File System, this bit indicates that the call has a parameter block with hierarchical information.
Do you make assumptions about the number and size of disk drives?
There are now five sizes of Apple disks for the Macintosh (400K, 800K, and 20M, 40M, 80M), as well as many more from third-party vendors. You should use Standard File and File Manager calls to determine the number and size of disk drives.
Do you depend on alternate (page 2) sound or video buffers?
Some Macintoshes do not support alternate sound and video buffers.
Do you print by sending ASCII directly to the printer driver?
To retain compatibility with both locally-connected and AppleTalk-connected printers, you should print using Printing Managerr, as documented in Inside Macintosh.
Does your application fail when it’s the startup application (i.e., without the Finder being run first)?
If so, you’re probably not initializing a variable. If your application does not work as the startup application, you should determine why and fix the problem, since it may cause your application to fail in the future.
º ◊# ˇ ˇˇˇˇ # ◊ † Ç
. Z Ä#
0Ià:µú9 " z ˇˇˇˇˇˇˇˇ # † ƒ ° d
ONLN f ˛ † å ° d 1drw2 … -·_ Ä ˇˇˇˇˇˇ è ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˙ ó@ † ò , Times
. R… R… +]ANew Technical Notes † ô ° d drw2 : °„ † ó ° d 1drw2 eÙ Ä ˇˇˇˇˇˇ P ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä E¿ † ò
( zïDeveloper Support † ô ° d drw2 : °„ † ó ° d `drw2 - Ô ˇˇˇˇˇˇ K Ô - Z e e Z ° d 1drw2 ¿˙È ˇˇˇˇˇˇ K ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : 0 ° ö ˇÙ Ä † ò
0 ( TÔ † ô ° d drw2 : °„ † ó ° d 1drw2 ÔÊ˙ ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˝Ä † ò
+& ® † ô ° d drw2 : °„ † ó ° d 1drw2  -¯ y ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä % † ò
( Y \ Macintosh † ô ° d drw2 : °„ † ó † ç ° d drw2 D † É
IR . ° d ONLN d m < ˛ ( ö ZCompatibility Guidelines
° d ONLN d 5 ô < • s ( ¡ Z Revised by: ° d ONLN d A ô Ñ • )HLouella Pizzuti ° d ONLN d Q ôµ •˛ ( ¡”February 1987 ° d ONLN d ` • < ± r ( Õ Z Written by: ° d ONLN d l • Ñ ± ª )H Cary Clark ° d ONLN d x •æ ±˛ ( Õ‹ January 1986 ° d ONLN d á ± Ñ Ω « ( Ÿ ¢Scott Knaster Ë X Ë ° d ONLN d ó ‚ < Óp (
Z=Apple has many enhancements planned for the Macintosh family ° d ONLN d ‘ ‚p Ó˛ (
é of computers. To help ensure ° d ONLN d Ò Ó < ˙ ¸ ( Z)your software’s compatibility with these ° d ONLN d Ó ¸ ˙˛ )¿5enhancements, check each item in this note to be sure ° d ONLN dP ˙ <
(" Z*that you’re following the recommendations. ° d ONLN d{ < Ö *FIf your software is written in a high-level language like Pascal or C ° d ONLN d¡Ö ˛ (:£and if you adhere to the ° d ONLN d⁄ <* ó (F Zguidelines listed in ° d ONLN dÔ ó* È )[Inside Macintosh ° d ONLN dˇ È*) )R, many of the ° d ONLN d
)*˛ )@,questions in this note won’t concern you. If ° d ONLN d:* <61 (R Z2you develop in assembly language, you should read ° d ONLN dl*16˛ )ı*each question carefully. If you answer any ° d ONLN dó6 <B î (^ Zquestion “yes,” ° d ONLN dß6 îB˛ )XByour software may encounter difficulty running on future Macintosh ° d ONLN dÍB <NΩ (j ZNcomputers, and you should take the recommended action to change your software. ° d ONLN d9Z <f ô *Do you depend ° d ONLN dGZ ôf˛ )]<on 68000 instructions which require that the processor be in ° d ONLN dÑf <r ò (é Zsupervisor mode? ° d ONLN dï~ <ä Ô *%In general, your software should not ° d ONLN d∫~ Ôä˛ )≥5include instructions which depend on supervisor mode. ° d ONLN dä <ñ [ (≤ ZThese ° d ONLN dˆä [ñ˛ ) Uinclude modifying the contents of the status register. Most programs which modify the ° d ONLN dLñ <¢` (æ Z>status register are only changing the Condition Code Register ° d ONLN däñ`¢˛ (æ~"(CCR) half of the status register, ° d ONLN d≠¢ <Æ › ( Z"so an instruction which addresses ° d ONLN dœ¢ ›Æ˛ )°:the CCR will work fine. Also, your software should not use ° d ONLN d
Æ <∫R (÷ Z;the User Stack Pointer (USP) or turn interrupts on and off. ° d ONLN dFΔ <“Æ *GDo you have code which executes in response to an exception and relies ° d ONLN dçΔÆ“˛ (ÓÃon the position ° d ONLN dù“ <fi (˙ Z-of data in the exception’s local stack frame? ° d ONLN dÀÍ <ˆ ¨ *Exception stack frames ° d ONLN d‚Í ¨ˆ˛ )pDvary on different microprocessors in the 68000 family, some of which ° d ONLN d'˘ < ‡ (! Z may be used in future Macintosh ° d ONLN dG˘ ‡¶ )§&computers. You should avoid using the ,
Courier ° d ONLN dmˆ¶ƒ )ΔTRAP ° d ONLN dq˘ƒ˛ )
instruction. ° d ONLN d < X (- ZNote: ° d ONLN dÑ Xe ) 5 You can determine which microprocessor is installed ° d ONLN dπe˛ (-Éby examining the low-memory ° d ONLN d’ < \ (< Zglobal ° d ONLN d‹ \! è ) CPUFlag ° d ONLN d„ è ¿ )3 (a byte at ° d ONLN dÔ ¿! fi )1$12F ° d ONLN dÛ fi I ) ). These are the values: ° d ONLN d, `8 ê (T ~CPUFlag ° d ONLN d, ®8 ˜ )Hmicroprocessor ° d ONLN d'8 `D y (` ~ $00 ° d ONLN d.8 ®D Δ )H68000 ° d ONLN d5D `P y (l ~ $01 ° d ONLN d<D ®P Δ )H68010 ° d ONLN dCP `\ y (x ~ $02 ° d ONLN dJP ®\ Δ )H68020 ° d ONLN dQ\ `h y (Ñ ~ $03 ° d ONLN dX\ ®h Δ )H68030 fi Xfi
(Ò ZCompatibility Guidelines (Ò1 ) of 5 ˇ ° ¿Ù%%DSIDICT:_cv
currentdict /bu known {bu}if
userdict /_cv known not{userdict /_cv 30 dict put}if
_cv begin
/bdf{bind def}bind def
currentscreen/cs exch def/ca exch def/cf exch def
/setcmykcolor where{/setcmykcolor get /cvcmyk exch def}{/cvcmyk{1 sub 4 1 roll 3{3 index add neg dup 0 lt{pop 0}if 3 1 roll}repeat setrgbcolor pop}bdf }ifelse
/ss{//cf //ca //cs setscreen}bdf
/stg{ss setgray}bdf
/strgb{ss setrgbcolor}bdf
/stcmyk{ss cvcmyk}bdf
/min1{dup 0 eq{pop 1}if}bdf
end
currentdict /bn known {bn}if
† ø ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6,Macintosh Technical Notes . 4 .˘
° d ONLN d (% *0Do you use low-memory globals not documented in ° d ONLN d 0 % (| ( DCInside Macintosh ° d ONLN d @ | (Ç )W? ° d ONLN d B 7 C 6 ( _ 6Other ° d ONLN d H 7 6 C¢ ) Kmicroprocessors in the 68000 family use the exception vectors in locations ,
Courier ° d ONLN d ì 4¢ D± ( _¿$0 ° d ONLN d ï 7± C⁄ ) through ° d ONLN d û C S - ( n 6$FF ° d ONLN d ° F - RI )7 in different ways. No undocumented location below the ° d ONLN d ÿ FI Rê ( ng
° d ONLN d Õ y Ÿ â )the ° d ONLN d Õ â Ÿ å ) ° d ONLN d Õ å Ÿ Ø )system ° d ONLN d
Õ Ø Ÿ ≤ )# ° d ONLN d Õ ≤ Ÿ Ω )or ° d ONLN d
Õ Ω Ÿ ¿ ) ° d ONLN d Õ ¿ Ÿ ¸ ) application ° d ONLN d Õ ¸ Ÿ ˇ )< ° d ONLN d Õ ˇ Ÿ )heaps ° d ONLN d Õ Ÿ ) ° d ONLN d Õ ŸI )starting ° d ONLN d( ÕI ŸL )) ° d ONLN d) ÕL ŸV )at ° d ONLN d+ ÕV ŸY )
° d ONLN d, ÕY Ÿù ) a hard-coded ° d ONLN d8 Õù Ÿ† )D ° d ONLN d9 Õ† ŸŒ )address? ° d ONLN dB Â Ò (
62The starting addresses and the size of the system ° d ONLN dt  Ò⁄ )Ò)and application heaps has already changed ° d ONLN dû Ò ˝ ¬ ( 6 (Macintosh vs. Macintosh Plus) ° d ONLN dΩ Ò ¬ ˝⁄ )™3and will change again in the future. Use the global ° d ONLN dÒ ˝
T (( 6ApplZone ° d ONLN d˘ T c )< to ° d ONLN d˝ c Ú ) find the application heap and ° d ONLN d ˝ Ú
( )èSysZone ° d ONLN d" ( ⁄ )6% to find the system heap. Also, don’t ° d ONLN dH à (4 6Pcount on the application heap zone starting at an address less than 65536 (that ° d ONLN dò à⁄ (4¶is, a system heap ° d ONLN d™ $ p (@ 6smaller than 64K). ° d ONLN dΩ0 < *1Do you look through the system’s queues directly? ° d ONLN dÔH T´ *QIn general, you should avoid examining queue elements directly. Instead, use the ° d ONLN d@H´T⁄ (p… Operating ° d ONLN dJT ` „ (| 6*System calls to manipulate queue elements. ° d ONLN dul x ' *Do ° d ONLN dwl 'x * ) ° d ONLN dxl *x = )you ° d ONLN d{l =x A ) ° d ONLN d|l Ax i )directly ° d ONLN dÑl ix m )( ° d ONLN dÖl mx ï )address ° d ONLN dål ïx ô )( ° d ONLN dçl ôx Ò )
screenBits ° d ONLN d · CÓ O˛ )E on ° d ONLN d  O < [ ï ( w Zmachines without ° d ONLN d ˆ O ï [˛ )YCColor QuickDraw. On machines with Color QuickDraw, the device list, ° d ONLN d: [ < g l ( É Z
described ° d ONLN dD [ l g )0#in the Graphics Devices chapter of ° d ONLN dg [ gj )´Inside Macintosh ° d ONLN dw [j g˛ )S!, tells the location and size and ° d ONLN dô j < v µ ( í Zbit depth of each screen, ° d ONLN d≥ g µ w ˙ )y
instructions? ° d ONLN dÊ ˝ < “ * In the future and on A/UX, all ° d ONLN d ˝ “ ˛ )ñ<32 bits of a master pointer may be used, with the flags byte ° d ONLN dB < c (4 Zmoved ° d ONLN dH cS )'(elsewhere. Use the Memory Manager calls ° d ONLN dp SÅ )HPurge ° d ONLN dv Åå )., ° d ONLN dx åÀ ) HNoPurge ° d ONLN dÄ À÷ )?, ° d ONLN dÇ ÷¸ ) HLock ° d ONLN dá ¸˛ )&, ° d ONLN dâ <( Æ (C ZHUnlock, HSetRBit ° d ONLN dö Æ' ≥ )r, ° d ONLN dú ≥( Á )HClrRBit ° d ONLN d§ Á' Ï )4, ° d ONLN d¶ Ï(- ) HGetState ° d ONLN dØ-'F )A, and ° d ONLN dµF(Ü ) HSetState ° d ONLN dæÜ'â )@ ° d ONLN døâ'˛ )to manipulate the master ° d ONLN dÿ' <3@ (O Z/pointer flags. (See the Memory Manager chapter ° d ONLN d'@3R (O^of ° d ONLN d
'R3Ë )Inside Macintosh Volume IV ° d ONLN d$'Ë3˛ )ñ for ° d ONLN d)3 <? º ([ Z information on these calls.) ° d ONLN dFK <WB *.Do you check for 128K, 512K, and 1M RAM sizes? ° d ONLN duc <o¥ *KYou should be flexible enough to allow for non-standard memory sizes. This ° d ONLN d¿c¥o˛ (ã“will allow your ° d ONLN d–o <{, (ó Z2software to work in environments like MultiFinder. ° d ONLN dá <ì§ *CIs your software incompatible with a third-party vendor’s hardware? ° d ONLN dGü <´ µ *If so, the incompatibility ° d ONLN dbü µ´˛ )y>may prevent your software from working on future machines. You ° d ONLN d°´ <∑u (” ZDshould research the incompatibility and try to determine a solution. ° d ONLN dÊ√ <œ5 *-Do you rely on system resources being in RAM? ° d ONLN d€ <Á x * On most of ° d ONLN d € xÁ˛ )<Iour systems, some system resources are in ROM. You should not assume, for ° d ONLN diÁ <Ûè ( ZEexample, that you can regain RAM space by releasing system resources. ° d ONLN dØˇ < 1 *.Does your software have timing-sensitive code? ° d ONLN dfi <#y *CVarious Macintoshes run at different clock speeds, so timing loops ° d ONLN d!y#˛ (?ó will be invalid. You can use ° d ONLN d>& <2 u (N Zthe trap call ° d ONLN dL# u3 ô )9Delay ° d ONLN dQ& ô2á )$4 for timing, or you can examine the global variable ° d ONLN dÖ#á3ß )ÓTicks ° d ONLN dä&ß2™ ) . fi Xfi
° d ONLN d (p *BDo you have code which writes to addresses within the code itself? ° d ONLN d C 4 @ù *EA memory management unit (MMU) may one day prevent code from writing ° d ONLN d à 4ù @⁄ ( \ª to addresses ° d ONLN d ï @ L ø ( h 6 within code memory. Also, some ° d ONLN d ¥ @ ø L⁄ )ß6microprocessors in the 68000 family cache code as it’s ° d ONLN d Î L XA ( t 6?encountered. Your data blocks should be allocated on the stack ° d ONLN d* LA X⁄ ( t_ or in heap blocks separate from ° d ONLN dJ X d ˛ ( Ä 61the code, and your code should not modify itself. ° d ONLN d| p |S *:Do you rely on keyboard key codes rather than ASCII codes? ° d ONLN d∑ à îU *CThe various keyboards are slightly different; future keyboards may ° d ONLN d˙ àU î⁄ ( ∞sbe different from them. For ° d ONLN d î †M ( º 6Atextual input, you should read ASCII codes rather than key codes. ° d ONLN dX ¨ ∏î *IDo you rely on the format of packed addresses in the trap dispatch table? ° d ONLN d¢ ƒ –c *EThe trap dispatch table is different on various Macintoshes. There’s ° d ONLN dÁ ƒc –⁄ ( ÏÅno guarantee of the trap ° d ONLN d ” fl ´ ( ˚ 6 table’s format in the future. ° d ONLN d ” ´ fl\ )ì You should use the system calls ,
Courier ° d ONLN d> –\ ‡¬ )±GetTrapAddress ° d ONLN dL ”¬ fl⁄ )f and ° d ONLN dQ fl Ô } (
6SetTrapAddress ° d ONLN d_ ‚ } Ó+ )e' to manipulate the trap dispatch table. ° d ONLN dá ˝ Â (% 6&Do you use the Resource Manager calls ° d ONLN d≠ ˙ Â
@ )Õ AddReference ° d ONLN dπ ˝@ Q )[ or ° d ONLN dΩ ˙Q
∏ )
RmveReference ° d ONLN d ˝∏ æ )g? ° d ONLN dà !§ (= 6NThese calls have been removed from the 128K ROM. They are no longer supported. ° d ONLN d- 9T *<Do you store information in the application parameters area ° d ONLN dW-T9⁄ (Ur(the 32 bytes between the ° d ONLN dq9 E (a 61application and unit globals and the jump table)? ° d ONLN d£Q ] ‘ *(This space is reserved for use by Apple. ° d ONLN dÃi u ˛ *-Do you depend on values in registers after a ° d ONLN d˘i ˛u⁄ )Ê)trap call, other than those documented in ° d ONLN d#u Å o (ù 6Inside Macintosh ° d ONLN d3u oÅ u )W? ° d ONLN d5ç ô Í (µ 6-These values aren’t guaranteed. The register ° d ONLN dbç Íôp )“conventions documented in ° d ONLN d|çpô√ )ÜInside Macintosh ° d ONLN dåç√ô⁄ )S will, ° d ONLN dìô •3 (¡ 69of course, be supported. Often, you may not realize that ° d ONLN dÃô3•⁄ (¡Q your code is depending on these ° d ONLN dÏ• ±7 (Õ 6<undocumented values, so check your register usage carefully. ° d ONLN d)Ω … */Do you use the IMMED bit in File Manager calls? ° d ONLN dY’ · *4This bit, which was documented in early versions of ° d ONLN dç’·. )ˆInside ° d ONLN dî’.·` ) Macintosh ° d ONLN dù’`·⁄ )2 as a special form of File ° d ONLN d∏· Ì ^ ( 6Manager call, ° d ONLN dΔ· ^Ì⁄ )FIactually did nothing for File Manager calls, and was used only for Device ° d ONLN dÌ ˘s ( 6IManager calls. With the advent of the Hierarchical File System, this bit ° d ONLN dYÌs˘⁄ (ëindicates that the call ° d ONLN dq˘ (! 64has a parameter block with hierarchical information. ° d ONLN d¶ *ADo you make assumptions about the number and size of disk drives? ° d ONLN dË) 5É *KThere are now five sizes of Apple disks for the Macintosh (400K, 800K, and ° d ONLN d3)É5⁄ (Q°20M, 40M, 80M), ° d ONLN dC5 Aó (] 6Gas well as many more from third-party vendors. You should use Standard ° d ONLN dä5óA⁄ (]µ
File and File ° d ONLN dòA M> (i 6>Manager calls to determine the number and size of disk drives. fi 4fi˘
. +Z,Developer Technical Support ( ,flFebruary 1987 . X .
° d ONLN d < (w ( D Z;Do you depend on alternate (page 2) sound or video buffers? ° d ONLN d < 4 < @Ä *BSome Macintoshes do not support alternate sound and video buffers. ° d ONLN d L < X{ *=Do you print by sending ASCII directly to the printer driver? ° d ONLN d Ω d < pÏ *VTo retain compatibility with both locally-connected and AppleTalk-connected printers, ° d ONLN d dÏ p˛ ( å
you ° d ONLN d p < |F ( ò Z7should print using Printing Managerr, as documented in ° d ONLN dN pF |ò ( òdInside Macintosh ° d ONLN d^ pò |õ )R. ° d ONLN d` à < îΔ ( ∞ ZLDoes your application fail when it’s the startup application (i.e., without ° d ONLN d¨ àΔ î˛ ( ∞‰
the Finder ° d ONLN d∑ î < † ì ( º Zbeing run first)? ° d ONLN d… ¨ < ∏à *YIf so, you’re probably not initializing a variable. If your application does not work as ° d ONLN d" ¨Ã ∏˛ ( ‘Í the startup ° d ONLN d. ∏ < ƒU ( ‡ Z;application, you should determine why and fix the problem, ° d ONLN di ∏U ƒ˛ ( ‡s#since it may cause your application ° d ONLN dç ƒ < – ñ ( Ï Zto fail in the future. fi Xfi
